📚 [북클럽] 나의 통찰 사냥기

서문

지난번 '보이게 일하라' 포스팅에 이은 두 번째 북클럽 도서입니다. 읽기전 호기심을 자극하는 부분이 있었습니다.

바로 함께 자라기의 저자이신 김창준님이 변역하신 책이라는 점입니다.

개인적으로 정말 재밌게 읽었던 책이어서, '통찰, 평범에서 비범으로' 책도 기대가 되었습니다.

책은 '통찰이 어떻게 촉발되는지', '무엇이 통찰을 방해하는지', '어떻게 통찰을 촉진 시킬수 있는지'에 대한 이야기로 구성되어 있습니다.

책의 구성에서 흥미로운 점은 실험실에서 실험의 결과로 통찰을 설명하기보다는, 이야기를 통해 통찰을 설명한다는 점 입니다.

이번 포스팅에서도 형식을 빌려 '이야기'를 통해 통찰을 살펴보고자 합니다.

목차

• 나의 잘못된 의도적 통찰 수련기
• 틸트! 모순을 통한 통찰 촉진기
• 통찰을 통한 성과 개선
• 마치며

나의 잘못된 의도적 통찰 수련기

'유레카'

아르키메데스가 순금관을 들고 목욕탕에 들어갔을 때 외친말로 유명한 단어입니다.

여러분도 샤워를 하는 도중이라던가 다른 무언가를 하면서 예상치 못한 번뜩이는 순간에 유레카를 외쳤던 경험이 있으신가요?

저는 저녁을 먹고 산책을 나서곤 합니다. 이직 준비를 하는중이라 그런지 어쩌다 한 번은 문득 이력서에 넣으면 좋을 단어들이 생각났습니다.

그래서 산책의 빈도를 늘리곤 했습니다. 의도적으로 통찰을 얻기 위해서.

그런데 늘어나는 산책의 횟수만큼 평소에 쉽게 떠오르지 않았던 단어들과 생각들이 선형적으로 늘지 않았습니다.

산책에서의 번뜩임은 단순히 우연이었던것일까요?

저자는 소용돌이와 난류(경험)가 많을수록 통찰의 발견 확률이 더 높아지는것을 인정하면서도,

우연적 발견의 확률을 더 높이기 위한 방법에 '그다지 열정적이지 않다.'라고 말합니다.

자칫 '거꾸로 사고하기의 오류'에 부딪힐 수 있다고 경고합니다.

저의 경우 산책의 빈도를 늘린것이 저자가 말하는 '거꾸로 사고하기의 오류'의 예시입니다.

산책에서의 번뜩임 경험을 통해 '산책 이라는 조건'을 만들어내면 통찰을 얻게 될 것이라고 생각했지만 그렇지 않은거죠.

저자는 '더 많은 무작위적 조합을 만들어낼수록 쓸모없는 것들을 걸러낼 부담 역시 커진다.'라는 말을 하면서 수학자 앙리 푸앵카레의 말을 인용합니다.

창조는··· 새로운 조합을 만드는 것에 있지 않다.··· 

그렇게 만들어진 조합들은 수적으로 무한할 것이고 그들 중 대다수는 전혀 관심을 둘 필요가 없는 것들이다. 

창조한다는 것은 반대로 불필요합 조합을 만들지 않는 것에 있다.

저자는 자신이 수집한 이야기중에서 통찰을 얻을 정도로 충분한 정보를 갖고 있었음에도, 통찰을 얻지 못한 사례들을 소개합니다.

이를 '대조적 쌍둥이 연구'라는 주제로 설명하죠. (실제 쌍둥이는 아님)

통찰을 얻지 못한 경우는 다음과 같습니다.

• 결함 있는 믿음에 사로잡힘
• 경험 부족
• 수동적 자세
• 구체적 추론방식

산책의 사례는 '우연'이었습니다. 산책과 단어는 연관이 없을수 있죠.

그렇다면 업무와 관련된 '세미나 참석'은 어떨까요?

부족한 경험을 채울수 있지 않을까요?

세미나에서 통찰을 얻었다고 해서 세미나 참석 횟수를 늘릴수록 통찰이 선형적으로 증가하진 않겠지만,

통찰의 기회를 놓치지 않기 위해서 배움의 기회를 늘리는 것은 유의미할 수 있겠습니다.

틸트! 모순을 통한 통찰 촉진기

책의 14장에서는 우리 자신의 통찰을 촉진시키는 방법들을 소개합니다.

제일 실용적이라고 생각했던 방법은 '모순'의 힘을 잘 활용하는 것이었습니다.

혼동, 모순, 갈등을 통찰을 얻기 위한 발판으로 사용하기만 한다면 우리는 언제든지 이를 스스로 찾을 수 있다. 

··· 

그것들을 발견하기 위한 시작이 된다.

··· 

우리는 그저 경악의 느낌을 호기심으로 바꾸기만 하면 된다.

책을 다 읽고나서 저에게 어떤 사례가 있을까 생각해봤습니다.

디버깅 경험이 생각났습니다.

다음은 저의 모순을 통해 통찰을 촉진시켰던 이야기입니다.

타입스크립트 공식 홈페이지의 플레이그라운드를 활용해서 타입스크립트를 연습해보는 도중 버그들을 발견했습니다.

오픈소스여서 버그를 직접 수정했고, 수정하는 과정에서 계속해서 새로운 버그들을 만나게 되었습니다.

버그를 수정할 때 프론트엔드 개발 환경에서 필수적인 HMR(Hot Module Replacement)이 동작하지 않는 문제였습니다.

이렇게 큰 프로젝트가 HMR이 없다는 사실이 혼란스러웠습니다.

아무래도 이상해서 공식 디스코드 채널에 질문을 남겼습니다.

다음은 그 대화입니다.

나: 질문이 있습니다. packages/playground/src에 있는 파일을 디버깅하고 있는데 변경사항을 확인하기 위해서 항상 pnpm bootstrap을 해야 할까요? HMR 같이 동작하도록 만들수 있을까요?

잭: 코드베이스의 구조화된 방식때문에 HMR 같은건 없습니다. 

나: 팁이 있을까요? 당신도 빌드후에 결과를 확인하나요?

오르타: 어떤 의미에서 빌드가 필요한가요? ··· 

나: 저는 함수를 테스트하고 있어요. 그래서 매번 pnpm bootstrap을 통해서 다시 빌드해야하는지 궁금합니다. 저는 파일의 참조를 변경해서 해결했어요.

오르타: 좋아요. 저는 pnpm dev를 통해 watcher를 사용하는것을 추천해요. 저장하면 자동으로 빌드를해주죠. ··· pnpm bootstrap은 한 번만 실행해야 해요.

💡 틸트!

(책에서는 모순을 발견할 때 틸트를 외칩니다.)

저는 pnpm dev를 통해서 개발환경에서 버그를 수정 하고 있었습니다.

그런데 오르타는 pnpm dev가 자동으로 빌드해준다고 말합니다.

모순이었습니다. 그의 말대로라면 자동으로 빌드가 수행되어서 별도의 명령어를 직접 작성하지 않더라도 수행되어야 합니다.

그래서 호기심을 갖고 오르타가 알려준 watcher 파일을 살펴봤습니다.

한 줄 한 줄 읽어보니 뭔가 이상한 부분이 있었습니다.

프로젝트의 패키지매니저는 pnpm인데, yarn에서 사용하는 workspace 명령어가 존재했습니다.

💡 틸트!

그래서 커밋 기록을 살펴봤습니다.

과거 yarn에서 pnpm으로 변경하는 과정에서 명령어 변경이 누락되었던것을 확인할 수 있었습니다.

이렇듯 모순에 호기심을 갖는것은 저자가 말한대로 통찰을 발견하기위한 시작점입니다.

대화를 하거나 글을 읽을때 내가 아는것과 다른 경우 '그런가보다'하고 넘기기 보다는,

적극적으로 호기심을 갖고 살펴보면 통찰로 갈 수 있지 않을까요?

통찰을 통한 성과 개선

성과 개선은 실수와 불확실성을 줄이고 통찰을 늘리는것이라고 합니다.

성과 개선 = 실수와 불확실성 ⬇️ + 통찰 ⬆️

조직에서 실수와 불확실성을 줄이기 위해 체크리스트를 만들고 단계를 추가하는 등 노력을 기울이지만,

통찰을 늘리는 방식은 고려되지 않는다는 이야기를 합니다.

그렇다면 어떻게 조직의 통찰을 늘릴수 있을까요?

조직의 통찰을 돕기 위한 방식중 하나로,

아이디어나 우려가 윗선에 도착하기전 필터링되지 않도록 우회하는 길을 제공하라고 합니다.

간혹 JD(Job Description)를 읽다보면 통찰을 늘리기 위한 조직의 노력을 엿볼수 있었습니다.

팀의 누구나 제안할 수 있으며, 이를 통해 다룰 수 있는 주제에는 한계가 없습니다. 

이러한 문구가 보이기 시작한것은 통찰의 민감도가 커진 덕분인것 같습니다.

마치며

포스팅에서는 '거꾸로 사고하기의 오류', '모순을 통한 통찰 촉진', '통찰을 통한 성과 개선'만을 다뤘습니다.

책에서는 우리가 일반적으로 통찰이라고 이해하고 있는 '순간적인 번뜩임'의 이외에도 다른 통찰의 경로를 소개합니다.

읽어보시면 표지에서 말하는 '남들이 보지 못하는 것들이 보이기 시작'하지 않을까 싶습니다.